Within the computing field, drivers are used to control or regulate another device. A software driver or device driver is a device-specific control program that enables a computer to work with a particular device, such as a printer or scanner. The device driver permits the computer system to communicate with the specific device. Because the driver handles device-specific features, the operating system is freed from the burden of having to understand and support the needs of the individual hardware devices. This is particularly important, given the number of different hardware devices currently being utilized.
The device drivers are typically developed based on a standard communication protocol. These protocols define a set of rules or standards upon which the drivers are written. As computer systems evolve, additional and different protocols can develop. The use of one protocol over another to develop a driver may expose or make available additional, desirable features of the device to which the driver pertains. As an example, within the imaging device context, drivers are currently being developed based upon the protocols known as TWAIN (Technology Without An Interesting Name) and WIA (Windows Imaging Acquisition).
For a device provider, such as an independent hardware vendor or IHV, it may be desirable to develop drivers based upon the WIA protocol rather than, or in addition to, the TWAIN protocol. It is often the case that the device provider will already have in place an existing driver based upon one protocol, such as the TWAIN protocol. But it is currently a non-trivial task to port existing drivers built on one protocol to a different protocol. The person tasked with the creation of a new driver based upon a driver from a different protocol must necessarily understand the technology associated with the existing driver. However, it is often the case that the developers of the existing driver are not the same individuals tasked with the creation of the new driver. Therefore, the developer of the new driver must first learn and understand the underlying architecture of the existing driver. At the same time, the developer must also understand the additional or new protocol architecture. Thus, although it is desirable to develop drivers in new architectures based upon existing drivers, it is currently a time-consuming and difficult task.
It is often the case that drivers have at least two layers. The top layer is a Device Driver Interface (DDI) layer, or application layer, and the bottom layer is the device protocol layer. Typically the operating system and/or applications interact with the driver via the DDI layer and the device protocol layer handles communication with the device. When the operating system wishes to communicate with the device, it makes a request via the DDI layer. The DDI layer then forwards this request to the device protocol layer. The device protocol layer converts the request into a device protocol specific request and then sends the request to the device. Similarly, when the device wishes to send an event to the operating system, the device protocol layer receives the event from the device, converts it to a DDI layer event and then forwards it to the DDI layer. The DDI layer is then responsible for notifying the operating system, which in turn notifies the intended recipient application.
It would therefore be beneficial to provide a method and a tool that facilitates the creation of device drivers based upon existing device drivers of a different architecture. A method and tool are needed that can create a base application layer for a device driver, given an existing driver of a different architecture. Given such a base application layer, a device provider can more easily port drivers from one architecture to another.